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Abstract 


The  current  conduct  of  operations  for  peace  keeping  or  disaster  relief  sees  the  increasing 
need  for  co-operation  among  different  national  agencies  and  nations,  to  collaborate  and  to 
maintain  awareness  of  the  status,  capabilities,  response  plans  and  C2  resources.  The 
urgency  and  scale  of  such  missions  bring  forth  the  need  for  seamless  transition  to 
operation,  as  well  as  the  need  for  better  interoperability  of  the  respective  systems  used 
among  the  national  agencies  and  the  coalition  partners. 

This  paper  presents  the  exploration  conducted  by  Defence  Science  and  Technology 
Agency  (DSTA)  on  enhancing  the  integration  between  C2  and  IT  (such  as,  human 
resource  and  logistic)  systems,  as  well  as  the  interoperability  between  new  and 
existing/legacy  systems.  In  the  exploration,  DSTA  uses  Command  and  Control 
Information  Exchange  Data  Model  (C2IEDM)  as  the  referential  data  model  for  building 
an  information  hub,  and  encapsulated  the  hub  with  a  set  of  open-standards  based  web 
services.  The  set  of  services  offered  a  consistent  way  of  accessing  and  updating  the 
information  hub,  while  maintaining  the  hub’s  integrity  by  enforcing  the  business  rules 
defined  in  C2IEDM.  In  addition,  the  set  of  services  also  shields  web  service  consumers 
from  the  complexity  of  the  model.  This  paper  will  discuss  on  the  information  integration 
architecture,  challenges  encountered  and  the  lessons  learnt  during  the  exploration,  while 
putting  the  state  of  the  art  data  model  into  practice. 


1  Introduction 


Recent  spate  of  natural  disasters,  such  as  Indian  Ocean  Tsunami  in  2004,  Hurricane 
Katrina  in  2005  and  Pakistan/Indian  earthquake  in  2005  are  massive  in  scale  and  required 
large  scale  relief  operations  involving  military,  government  agencies  and  Non- 
Govemment  Organisations  (NGOs).  The  urgency  of  such  operations  require  resources  to 
be  pooled  together  quickly  and  moved  rapidly  to  the  affected  areas  while  maintaining  full 
visibility  and  accountability  of  personnel  and  equipment  involved  in  the  operation. 

The  past  paradigm  of  having  separate  systems  within  military,  NGOs  and  other 
governmental  organisations  storing  and  processing  their  own  silos  of  information  could 
no  longer  support  the  urgency  and  mix  of  resources  for  such  an  operation.  The  need  for 
an  integrated  system  of  systems  that  have  access  to  critical  resource  information  residing 
in  all  these  systems  is  immediate,  so  that  a  disaster  relief  team  spanning  across  different 
organisations  could  be  put  in  place  within  the  shortest  possible  time. 

In  its  search  for  a  solution  to  meet  this  need,  an  exploration  was  initiated  as  an  attempt  to 
integrate  information  residing  in  human  resource  and  C2  systems  into  a  common 
information  hub.  As  force  management  functionality  matches  closely  to  the  requirement 
of  this  exploration  to  manage  and  monitor  relief  teams,  a  Force  Management  System 
(FMS)  prototype  was  developed  for  prove  of  concept.  The  prototype  FMS  consumes  the 
set  of  services  that  were  built  on  top  of  C2IEDM  and  presents  a  complete  force  structure 
and  statuses  to  the  user.  In  this  paper,  we  discuss  on  the  exploration  conducted,  the 
challenges  encountered  and  the  lessons  learnt,  using  FMS  for  illustration.  In  Section  2, 
we  discuss  on  the  usage  of  C2IEDM  as  the  base  model  to  develop  an  information  hub  for 
information  integration.  In  Section  3,  we  discuss  on  usage  of  web  services  to  build  an 
interface  for  shielding  the  complexity  of  C2IEDM  from  application  developers.  We 
discuss  on  the  FMS  prototype  developed  for  this  exploration  in  Section  4.  Lastly,  we 
discuss  on  the  lessons  learnt  and  conclusion  in  Section  5. 


2  Information  Integration 

Order  of  Battle1  [1]  (Orbat)  is  commonly  used  in  C2  systems  by  military  planners  for 
organising  different  force  structures  to  tackle  different  situations.  Disaster  relief 
operations  have  similar  requirement  to  have  an  organisation  structure  comprising  of 
resources  from  military,  government  agencies  as  well  as  NGOs,  in  order  to  maintain 
visibility  and  accountability  of  the  people  and  equipment  involved  in  the  operation. 

Information  on  organisation,  people  and  equipment  exists  today  in  IT  systems  that  are 
used  in  day  to  day  operation,  as  well  as  C2  systems  that  are  used  for  peacetime  planning, 
training  and  operations.  However,  the  challenge  to  inter-operate  and  share  information 
among  these  systems  is  a  commonly  known  NxN  problem  as  illustrated  in  Figure  1. 
Essentially,  the  diagram  shows  that  interfaces  between  stove-piped  systems  are 


1  Defined  by  US  DOD  and  NATO  as  the  identification,  strength,  command  structure,  and  disposition  of  the 
personnel,  units,  and  equipment  of  any  military  force. 


proprietary,  which  require  systems  to  build  an  interface  to  every  other  system  that  it 
needs  to  communicate  with.  This  way  of  interoperability  results  in  NxN  number  of 
interfaces  required,  where  N  is  the  number  of  systems  in  the  network. 
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Figure  1:  The  NxN  Problem 


Part  of  the  objectives  in  this  exploration  is  to  reduce  the  problem  from  a  NxN  to  a  N+l 
problem  as  illustrated  in  Figure  2.  The  strategy  is  to  integrate  various  systems  through  a 
common  web-service  interface  that  provides  a  common  access  to  the  information  hub, 
developed  based  on  C2IEDM.  Through  this  interface,  each  system  that  is  added  to  the 
network  will  just  need  to  build  one  single  interface  to  this  common  web-service  interface 
and  the  system  will  be  interoperable  with  the  rest  of  the  systems  on  the  network.  Thus, 
this  strategy  will  essentially  reduce  the  number  of  interfaces  required  to  N+l. 
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Figure  2:  Reduction  to  a  N+l  Problem 


The  Multilateral  Interoperability  Programme  (MIP)  C2IEDM  is  chosen  as  the  referential 
data  model  for  this  exploration  as  it  supports  majority  of  the  entities  required  for 
capturing  Orbat  information.  MIP’s  aim  is  “to  achieve  international  interoperability  of 
Command  and  Control  Information  Systems  (C2IS)  at  all  levels  from  corps  to  the  lowest 
appropriate  level,  in  order  to  support  combined  and  joint  operations.”  [2],  Adopting 
C2IEDM  could  lead  to  better  interoperability  with  MIP-compliant  C2IS  from  other 
nations  that  are  involved  in  the  relief  operations.  In  addition,  as  C2IEDM  is  jointly 
developed  by  26  MIP  members  including  many  NATO  countries,  adopting  the  model 
would  mean  tapping  on  the  operational  experience  of  these  members  in  defining  the 
model.  As  the  exploration  is  evolutionary,  the  MIP  Data  Exchange  Mechanism  (DEM)  is 
slated  to  be  explored  in  subsequent  phases  of  the  project  and  thus  will  not  be  discussed  in 
this  paper. 

Although  C2IEDM  is  able  to  capture  majority  of  the  Orbat  related  information  stored  in 
current  IT  and  C2  systems,  the  model  needs  to  be  extended  with  additional  dependent 
entities  (eg.  Appointment  and  Person-Course),  relevant  relationships  and  additional 
domain  values  (national  specific),  in  order  to  capture  all  essential  information.  In  this 
case,  Appointment  and  Person-Course  are  required,  such  that  the  person  holding  the 
appropriate  appointment  and  equipped  with  the  correct  training  is  being  assigned  to 
tackle  different  scenarios  of  the  relief  operation.  Figure  3  shows  the  extension  to  the 
model.  These  extensions  answered  to  the  needs  of  national  requirement  on  the  model, 
however,  it  poses  a  problem  for  international  interoperability,  as  MIP  DEM  specifies  that 
all  C2IEDM  databases  using  the  DEM  for  data  synchronisation  must  use  the  same 
version  of  the  model.  Though  MIP  DEM  is  not  addressed  in  the  current  phase  of  the 
exploration,  an  option  being  considered  is  to  develop  a  mapping  from  the  national 
information  hub  to  a  standard  C2IEDM  that  is  meant  for  international  interoperability. 


Figure  2:  Extension  to  C2IEDM 

Figure  4  shows  the  mapping  between  systems  that  use  different  data  models.  A  set  of 
mappings  is  created  for  each  system  that  uses  non-C2IEDM  data  model.  Information 


from  systems  with  proprietary  data  model  is  mapped  to  the  national  information  hub, 
which  is  based  on  extended  C2IEDM.  As  the  extended  model  could  not  be  replicated 
directed  with  standard  C2IEDM,  a  mapping  between  the  extended  model  and  the 
standard  model  is  created  as  well.  The  data  is  then  replicated  from  the  National 
Information  Hub  to  the  standard  C2IEDM  through  the  mapping  defined.  As  can  be  seen 
from  the  diagram,  national  systems  could  maintain  their  international  interoperability 
though  they  are  running  on  an  extended  C2IEDM.  In  addition,  this  architecture  could  also 
shield  national  systems  running  on  extended  C2IEDM  from  the  changes  of  evolving  MIP 
Blocks2.  The  impact  of  the  evolving  MIP  blocks  on  national  systems  can  thus  be 
restricted  to  the  mapping  module  between  the  extended  model  and  the  standard  model, 
reducing  the  maintenance  required  significantly  as  compared  to  maintaining  and 
migration  National  systems  as  and  when  a  new  C2IEDM  version  is  released. 
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Figure  4:  Mapping  between  Different  Data  Models 


3  Common  Interfaces 

Dr  Michael  Schmitt  [3]  proposed  a  model  for  C2IEDM  data  access  in  his  paper,  titled 
“Integration  of  the  MIP  Command  and  Control  Information  Exchange  Data  Model  into 
National  Systems”.  The  considerations  for  using  the  data  access  model  are: 


2  MIP  releases  a  new  ‘Block’  every  three  years  that  remains  ‘in-service’  for  two  years. 


•  Maintainability  -  MIP  data  model  undergoes  frequent  updates.  C2IS  that 
relies  on  the  relational  schema  of  the  model  has  to  be  adapted  with  every 
model  update,  resulting  in  poor  maintainability. 

•  Efficiency  -  C2IEDM  is  primarily  designed  for  information  exchange  and  is 
not  optimised  for  fast  data  access.  To  improve  efficiency,  high  level  data 
objects  should  be  defined  that  abstract  from  the  complexity  of  the  data  model. 

•  Correctness  -  C2IEDM  has  some  potential  pitfalls,  which  can  result  in 
erroneous  data  if  used  improperly.  Common  operations  should  be  handled 
centrally  to  ensure  correctness  of  the  data. 

In  addition  to  the  above  considerations,  the  following  are  being  considered  as  well: 

•  Complexity  -  The  complexity  of  the  model  resulting  in  steep  learning  curve. 
The  complexity  also  resulted  in  the  need  of  complex  SQL  statements  for 
retrieval  of  desired  data.  By  building  a  common  interface  on  top  of  the  model, 
the  complexity  of  the  model  could  be  shielded  from  business  application 
developers  by  leveraging  on  the  knowledge  of  the  current  team. 

•  Accessibility  -  Building  on  Dr  Michael’s  model,  a  common  interface  using 
XML  based  web  services  was  implemented.  Using  the  Service  Oriented 
Architecture  (SOA)  framework  [4],  the  interface  implemented  is  loosely 
coupled  and  could  be  reuse  by  other  applications  or  services.  The  services 
could  be  accessed  by  distributed  systems  through  discovery  and  consumption 
of  the  services  developed.  In  addition,  the  layer  of  web  services  also  ensures 
the  integrity  and  consistency  of  data  during  retrieval  and  updates  to  the  model 
by  enforcing  business  rules  mandated  in  MIP  documentation. 

Figure  5  shows  the  architecture  for  the  interface.  As  web  services  are  generally 
considered  as  a  pull  mechanism,  a  push  mechanism  using  Publish  &  Subscribe  (P&S) 
mechanism  was  incorporated  for  pushing  updates  of  units  and  personnel  to  systems  that 
have  subscribed  to  the  topic  of  interest.  XML  based  messages  with  schemas  that  reuses 
C2IEDM  entities  were  adopted  for  ease  of  interpretation  by  the  receiving  systems. 


4  The  Prototype 

A  force  management  system  prototype  was  developed  to  validate  the  concept  of 
integrating  IT  and  C2  systems  through  C2IEDM  and  the  web  service  interface.  Force 
management  was  chosen  to  assess  on  the  ability  of  this  concept  in  supporting  the 
requirement  of  forming  a  disaster  relief  team  quickly  and  to  account  and  track  the 
resources  deployed  in  the  operation.  A  set  of  force  management  web  services  was 
developed,  which  act  as  the  application  interface  to  the  model.  In  addition  a  force 
management  front-end  was  developed  to  demonstrate  the  inter-operability  of  new  and 
existing  systems  through  the  interface. 
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Figure  3:  System  Architecture 

The  US  Default  Operational  Organisation  (DOO)  concept  [5]  was  adopted,  whereby  a 
stable  default  organisation  structure  is  created  and  maintained  such  that  relief  teams  could 
be  easily  created  prior  to  operations  by  re-linking  the  relations  between  the  organisations 
in  the  DOO.  In  the  prototype,  information  from  human  resource  systems  is  mapped  and 
transferred  into  the  model.  Additional  conceptual  organisations,  used  primarily  during 
operations  for  aggregation  and  reporting  of  sub-units  statuses,  were  created  subsequently 
using  information  from  C2  systems,  to  form  the  DOO. 

A  sample  DOO  (Orbat  Template)  is  shown  on  the  left  frame  of  the  prototype’s  User 
Interface  (UI)  in  Figure  6.  The  middle  frame  shows  the  organisation  structure  of  the  relief 
team  (TF)  that  is  created  by  “dragging”  the  relevant  organisations,  appointments  and 
personnel  from  the  DOO.  This  demonstrated  the  ability  of  the  prototype  to  create  a 
disaster  relief  team  rapidly.  At  the  back  of  the  UI,  such  actions  performed  by  users  are 
interpreted  to  various  web  service  calls  to  the  interface  layer  for  retrieval  and  updates  to 
the  ODS. 

The  statuses  of  the  organisations  involved  in  the  operations  are  simulated  by  a  C2  system 
by  submitting  reports  through  the  P&S  mechanism.  An  existing  system  was  identified  to 
demonstrate  the  interoperability  through  the  interface  by  building  a  web  service  client 
that  consumes  the  set  of  force  management  services  and  display  organisations’  statuses 


on  a  map  display.  The  advantage  of  the  interface  was  clearly  visible  as  it  took  the 
development  team  minimal  effort  of  just  over  3  weeks  to  be  inter-operable  with  existing 
IT  and  C2  systems.  The  existing  system  brought  in  just  need  to  develop  the  additional 
interface  to  the  model,  instead  of  building  multiple  interfaces  to  the  IT  and  C2  systems, 
thus  reducing  the  time  and  effort  significantly. 

The  right  frame  of  the  UI  in  Figure  6  shows  the  statuses  of  personnel  and  organisations, 
while  the  bottom  frame  of  the  UI  shows  the  personnel  details  mapped  from  the  human 
resource  systems.  Figure  7  shows  the  UI  of  the  existing  system  displaying  the  location 
statuses  of  relevant  units  retrieved  through  the  FMS  service. 


Figure  6:  Force  Management  User  Interface 


Figure  7:  Map  Interface  for  Situation  Awareness 


5  Lessons  Learnt 


During  the  exploration,  several  issues  were  encountered,  which  we  shall  discuss  in  this 
section.  The  issues  are: 

•  C2IEDM  extensions 

As  discussed  earlier,  the  model  was  extended  to  cater  for  national  information 
requirements.  The  key  principles  of  C2IEDM  extensions  were  followed: 

i.  The  basic  C2IEDM  data  representations  are  not  changed,  and 

ii.  Extensions  are  always  done  in  the  least  obtrusive  manner,  i.e., 

(a)  new  information  is  modelled  by  new  attribute  values  first.  If 
this  is  not  sufficient, 

(b)  the  category  and  subcategory  codes  are  extended  in  order  to 
generate  new  subtypes  of  existing  concepts.  If,  and  only  if  this 
is  not  sufficient, 

(c)  new  concepts  and  associations  are  introduced. 

However,  some  interoperability  problems  could  still  exist  even  if  the  principles 
were  followed  closely.  Two  main  cases  where  problems  will  arise  is  as  follow: 

i.  When  the  model  is  extended  with  new  attribute  value/category, 
other  nation’s  C2IEDM  without  similar  extensions  will  encounter 
problem  while  interpreting  the  new  attribute/category  introduced. 

One  way  to  overcome  this  is  to  maintain  the  standard  attribute 
values  and  category  codes,  while  creating  extended  tables  which 
will  be  referenced  by  national  systems  when  they  encountered 
values  such  as  ‘not  specified’  or  ‘not  otherwise  specified’.  For 
instance,  in  Figure  3,  when  national  system  encounter  an 
organisation  with  the  organisation-category-code  specified  as  ‘not 
otherwise  specified’,  it  will  lookup  the  ‘Appointment’  entity  for 
detail  information.  For  cases  where  there  are  several  new 
subcategories  to  be  introduced,  we  could  branch  ‘not  otherwise 
specified’  category  in  the  ‘organisation’  entity  into  another  whole 
set  of  subcategories  and  their  relevant  entities  which  are  visible 
only  to  national  systems.  For  other  nation’s  C2IEDM,  they  will 
only  know  that  the  particular  organisation  in  concern  is  of  ‘not 
otherwise  specified’  class. 

ii.  Introduction  of  additional  attribute  to  existing  entity  will  cause 
interoperability  problem  as  DEM  requires  all  C2IEDM  involve  in 
the  replication  to  be  of  the  same  version. 


Another  approach  under  consideration  to  overcome  this  is  to 
maintain  the  standard  C2IEDM  entity  as  it  is  while  creating  new 


national  entity  that  have  a  primary  key  which  references  to  the 
entity  requiring  extension.  For  instance,  the  PERSON-COURSE 
entity  in  Figure  3  is  a  new  national  entity,  which  references  to 
PERSON  entity.  Any  additional  information  that  needs  to  be 
captured  can  then  be  included  in  the  new  entity.  As  there  are  no 
changes  to  PERSON  entity  and  the  existence  of  new 
entity/relationship  is  transparent  to  other  nation’s  C2IEDM,  the 
interoperability  problem  can  be  avoided  while  still  addressing 
national  information  requirements. 


Performance 

During  the  development  of  the  prototype,  there  was  performance  issues  when 
using  web  services  and  the  model.  Though  the  prototype’s  focus  is  not  on 
performance  optimisation,  a  brief  study  was  performed  to  look  into  the  problems 
and  the  following  were  identified: 

i.  Synchronous  services  were  used  for  retrieving  relatively  large  amount  of 
information  initially,  causing  a  sluggish  front-end.  To  overcome  this, 
synchronise  web  services  was  invoked  for  fast  retrieval  of  high  level 
organisations  while  asynchronous  web  services  were  invoked  in  the  back-end 
for  retrieval  of  detail  information  concurrently.  This  provides  a  responsive 
front-end  with  details  being  populated  subsequently  from  asynchronous  web 
services  returns. 

ii.  Due  to  the  highly  normalised  design  of  the  model,  the  SQL  queries  are 
complex  and  computational  intensive,  resulting  in  slow  performance.  A 
proposal  is  to  create  accelerated  tables  for  keeping  frequently  accessed 
information.  Alternatively,  the  web  services  layer  could  be  implemented  on 
top  of  the  data  access  stack  proposed  by  Dr  Michael  [3]. 

iii.  The  problem  with  slow  performance  of  complex  SQL  queries  is  compounded 
by  the  amount  of  records  to  be  kept  in  C2IEDM  that  grows  overtime  due  to 
the  basic  principle  that  no  data  should  be  deleted  from  the  model.  To  keep  the 
amount  of  records  in  the  model  in  check,  proper  archiving  of  the  model  will 
need  to  be  put  in  place  should  the  nation  intends  to  use  the  model  for 
continuous  operation.  Issues  such  as  whether  the  IDs  should  be  recycled  when 
existing  information  is  archived  will  need  to  be  addressed. 

Mapping 

The  other  major  issue  encountered  is  the  mapping  between  data  model  in  existing 
systems  and  C2IEDM.  As  the  data  model  for  existing  systems  were  designed  to 
meet  individual  system’s  needs,  the  design  concepts  for  their  models  deviate  from 
each  other  as  well  as  C2IEDM.  This  posed  a  challenging  mapping  issue,  often 
require  manual  intervention  to  ensure  that  the  mapping  is  complete  and  correct.  In 


addition,  customised  mapping  script  will  need  to  be  written  to  complement  the 
standard  mapping  functions  provided  by  Commercial  Off  The  Shelf  (COTS) 
mapping  tools.  It  is  thus  recommended  that  the  design  of  new  systems  should 
factor  in  the  support  for  a  complete  mapping  to  C2IEDM  so  as  to  avoid  such 
issues  in  the  future. 


6  Summary  and  Conclusions 

In  this  paper,  we  have  discussed  on  the  exploration  of  integrating  new/existing  IT  and  C2 
systems  through  a  common  interface  build  on  top  of  a  C2IEDM  based  Information  Hub. 
We  have  demonstrated  the  potential  of  such  interface  through  the  force  management 
prototype  developed  during  the  exploration.  Although  the  current  work  did  not  look  into 
MIP  DEM,  we  do  not  foresee  much  difficulty  incorporating  DEM  for  inter-operability 
with  other  nations.  We  have  discussed  key  lessons  learnt  from  the  exploration  and 
proposed  approaches  to  overcome  several  challenges. 
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■  Extensions  to  C2IEDM  must  be  done  with  care. 
Consider  the  suggestions  provided  in  this 
presentation  to  avoid  interoperability  issues 

■  Use  interim  layers  to  buffer  the  model’s  complexity 
and  version  changes  to  the  model 

■  Design  your  data  model  with  mapping  to  C2IEDM  in 
mind 
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